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ABSTRACT 

i 

The  temporal  properties  of  objects  in  s  real-time,  distributed,  fault-tolerant ,  reac¬ 
tive  operating  systems  are  defined  and  analyzed.  Accordingly,  properties  associated 
with  the  schedulability  of  accepted  jobs  whose  deadlines  are  guaranteed  are  examined. 
Special  mechanisms  that  support  temporal  inference  are  proposed.  These  mechanisms 
support  explicit  time  expression,  precedence  relations,  and  projections  of  the 
knowledge  of  real-time  at  different  localities.  Special  data  structures,  called  calen¬ 
dars,  are  proposed  for  management  and  planning  of  activities  and  for  scheduling.  Al¬ 
gorithms  that  verify  schedulability  of  arriving  requests  are  introduced,  ensuring  that 
already-given  guarantees  for  already-accepted  jobs  are  not  violated.  4 _ 
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1  Introduction 


In  this  paper  we  examine  some  aspects  of  the  use  of  objects  as  the  building  blocks  for  con¬ 
structing  a  real-time  reactive  system.  A  reactive  system  repeatedly  responds  to  requests 
from  its  environment  by  producing  outputs  ({8]).  In  our  case  the  requests  are  invocations 
of  executable  objects.  The  temporal  properties  that  the  objects  in  the  system  demonstrate, 
characterise  the  whole  system’s  temporal  and  functional  behavior.  Therefore,  when  de¬ 
signing  a  real-time,  distributed  and  fault-tolerant  reactive  operating  system,  the  temporal 
properties  of  its  objects  are  of  crucial  importance. 

One  major  property  in  the  temporal  behavior  of  a  hard  real-time  operating  system  is  the 
reliability  of  the  guarantee  it  provides  for  satisfying  time  constraints  of  jobs  it  has  already 
accepted.  This  guarantee  is  the  focus  of  this  paper.  A  guarantee  of  this  kind  depends 
on  the  way  in  which  new  jobs  are  accepted  and  on  verification  of  the  schedulability  of  a 
new  job  before  accepting  it.  In  this  paper  we  propose  mechanisms  that  support  temporal 
inference  requirements  for  schedulability  verification,  along  with  algorithms  that  carry  out 
the  verification. 

The  paper  is  organised  as  follows.  In  the  remaining  of  this  section  we  outline  the  object 
architecture  concept,  the  meaning  of  a  deadline  guarantee  in  a  real-time  system,  and  the 
participation  of  the  time-service  in  the  system  management  scheme.  The  following  section 
provides  notations  for  descriptions  of  temporal  properties  and  relations.  The  proceeding 
section  describes  the  concept  of  calendars  as  means  of  resource  allocation  management, 
object  sharing,  and  deadline  guarantee.  The  next  section  examines  various  properties  of 
an  object’s  calendar.  The  paper  closes  with  some  concluding  remarks. 

1.1  Objects  Architecture:  A  Review  of  Previous  Work 

In  [15,16]  we  have  introduced  an  architecture  for  designing  hard1  real-time  operating  sys¬ 
tems.  This  architecture  is  based  on  the  use  of  highly  encapsulated  entities,  called  objects. 
An  object  is  a  distinct  and  selectively  accessible  software  element  that  resides  on  one  of 
the  storage  resources  of  the  system.  The  objects  architecture  defines  the  objects  as  the 
elements  that  constitute  the  system.  It  also  defines  their  classification,  the  relationships 
between  them,  the  set  of  operations  they  are  subjected  to  and  execution  parameters  that 
permit  scheduling  them  for  execution  and  access. 

Many  software  engineering  research  efforts  have  been  invested  in  the  use  of  objects  to 
establish  a  concurrent  programming  development  environment.  In  this  context  an  object 
is  captured  as  an  entity  whose  behavior  is  characterized  by  the  operations  it  is  subjected 

‘Hard  ml  tlma  ayatama  an  charaetariaad  by  thair  proparty  of  haring  a  nonraearambla  fault  whan  a  computation  la  not 
oomplata  bafera  ita  daadllna. 


to  and  the  operations  it  carries  out  on  other  objects.  The  external  view  of  an  object  (these 
operations)  is  its  specification,  and  the  internal  view  of  an  object  is  its  implementation. 
We  have  previously  introduced  a  point  of  view  which  is  slightly  different.  There,  we  have 
considered  the  use  of  objects  architecture  in  a  system  context,  thereby  expanding  the  above 
object  definitions  to  describe  elements  and  entities  in  a  more  general  way.  Yet,  some  of 
the  properties  that  characterize  objects  in  software  development  context  ([3])  are  valid  in 
the  system  architecture  context  as  well,  in  that: 

•  An  object  has  a  state. 

•  There  is  a  set  of  actions  to  which  an  object  is  subjected  and  a  set  of  actions  it  requires 
from  other  objects. 

•  It  is  denoted  by  a  name. 

•  It  has  restricted  visibility  of  (as  well  as  by)  other  objects. 

We  have  shown  how  our  object-oriented  system  design  methodology  provides  means  to 
construct  systems  with  a  high  degree  of  deterministic  and  predictable  timing  properties. 
This  determinism,  together  with  the  required  fault  tolerance  schemes,  set  up  a  time  con¬ 
straint  oriented  system.  In  the  above  papers  we  have  defined  a  classification  of  object 
types,  the  set  of  operations  each  of  the  object  types  is  associated  with,  and  their  rela¬ 
tionships.  A  conceptual  model  has  been  considered  in  our  analysis  of  the  applicability  of 
objects  architecture  for  a  real-time  distributed  fault  tolerant  operating  system.  Issues  of 
creation,  deletion  and  access  for  manipulation  and  state  verification,  have  lead  us  to  define 
the  joint  that  contains  the  following  parts: 

•  A  context  independent  pointer  for  the  naming  network,  to  allow  a  multi-user,  selective 
sharing  of  the  object. 

•  An  owner  /user  justification  structure. 

•  Resource  requirements. 

•  A  ticket  check  mechanism  for  the  protection  scheme. 

•  A  time  constraint  for  an  executable  object. 

•  A  replica/altemative  control  mechanism  for  the  fault  tolerance  scheme. 

In  our  model,  objects  that  relate  to  each  other,  or  in  other  words  objects  that  satisfy 
a  given  semantic  link,  are  connected  via  the  owner/user  justifications  in  the  joint.  These 
relationships  are  in  accordance  with  the  visibility  restrictions  and  the  set  of  operations  to 
whom  the  justificand  is  subjected  and  the  justifier  operates  on.  We  can  model  a  system  as 


a  graph  whose  nodes  are  objects  and  whose  arcs  are  directed  from  justifier  to  justificand 
representing  the  owner/user  relationship.  An  example  is  given  in  Figure  1. 

In  [3]  three  classes  of  operation  types  on  objects  are  defined: 

•  Operations  that  change  an  object  state. 

•  Operations  that  evaluate  current  state  of  an  object. 


•  Operations  that  allow  visiting  parts  of  an  object. 

These  operations  can  be  carried  out  on  object  bodies  as  well  as  on  object  joints. 

We  have  also  discussed  the  distinction  between  on-line  and  off-line  (infinite  deadline) 
execution  of  objects.  Scheduling  executable  objects  and  context  initialization  are  each 
divided  in  our  model  into  an  on-line  part  and  an  off-line  part.  The  context  initializer 
consists  of  an  off-line  allocator /binder  that  manages  the  acceptance  of  jobs  (requests  to 
execute  objects)  and  allocates  the  resources  before  loading  and  an  on-line  loader  that 
activates  schedulable  objects  that  are  invoked.  The  scheduling  policy  is  managed  by  the 
off-line  scheduler  and  the  on-line  scheduler  carries  out  locally  the  policy,  and  dispatches 
loaded  objects  according  to  their  time  constraint.  The  verification  of  the  schedulability  of 
an  executable  object  is  a  prime  issue  in  this  paper,  and  is  expanded  in  section  3. 

Executable  objects  can  be  divided  into  three  type  classes  ([3]),  depending  on  their 
relationships  with  other  objects.  Since  our  definition  of  an  object  is  slightly  different  from 
that  of  software  engineering,  we  modify  this  classification: 

•  Actor.  An  object  which  is  subjected  to  no  operation.  It  only  operates  on  other  objects. 

•  Server.  An  object  which  is  only  subjected  to  operations  by  other  executable  objects. 
It  does  not  operate  on  other  executable  objects,  but  it  may  operate  on  non-executable 
objects. 


•  Agent.  An  object  which  operates  on  (one  or  more)  executable  objects  on  behalf  of 
another  executable  object.  In  turn  other  executable  objects  may  operate  on  it. 

In  addition  there  are  the  non-executable  objects,  which  are  only  subjected  to  operations. 

•  Passive:  An  object  which  is  only  subjected  to  operations  and  does  not  operate  on 
others. 

The  relationships  between  objects  necessitate  the  grouping  of  objects  of  the  same  type 
into  a  meta-object,  to  whom  the  rest  of  the  objects  may  refer  to  as  a  whole  entity. 

1.2  Time-Service  in  Hard  Real-Time  Systems 

In  our  system  model  computations  are  described  as  graphs,  where  the  vertices  (nodes)  are 
executable  objects  and  the  edges  are  relations  between  them.  Being  a  real-time  system, 
each  of  the  active  objects  in  the  system  is  assumed  to  have  an  access  to  a  “time-knowledge” 
resource,  usually  called  a  clock.  Let  C<(t)  be  the  monotonic  function  that  maps  real¬ 
time  (sometimes  called  global  time  or  universal  time)  to  clock-t  time.  The  clocks  in  the 
system  are  inaccurate  due  to  a  nonzero  drift-rate.  This  inaccuracy  results  in  incorrect 
time  readouts,  in  other  words  C,-(t)  t.  Clock  synchronization  algorithms  (for  examples 
one  may  refer  to  [11,12,17,7,23,6])  result  in  having  a  local  drift  rate  which  is  bounded. 
Therefore,  each  computation  is  assumed  to  be  able  to  access  a  clock,  and  acquire  the 
estimate  of  the  current  real-time  C,(f)  =t±  A <(t),  through  the  use  of  a  time  server. 

Assuming  that  time  servers  use  a  linear  clock  interpretation,  the  service  for  a  get-time 
request  at  computation  node  p  is  a  construction  of  Tp,  for  t  >  t(°\  by 

TP(t)  =  a,(t)C,W  +  bp(t) 

where  Cp(t)  is  the  local  clock  which  is  periodically  synchronized  at  least  every  J  time  units 
with  the  other  clocks  in  the  system.  Let  the  synchronization  local  times  be  denoted  by  the 
sequence  <W.  One  possible  definition  of  the  coefficients  Op(f),  bp(t)  is  described  in  [13]: 

•  tp°)  <  t  <  tj,1);  (initial  coefficients) 

<■,(*)  = 

•  <  t  <  t£+1),»  >  0:  (coefficients  update) 


W«)  =  +  ( •At")  -  «,(<?>) ) 


Figure  2:  Object’*  Owner  and  Ueer  Temporal  Justification 

We  define  event  as  a  detectable  instantaneous  atomic  change  in  a  system  state.  In 
a  real-time  system,  the  state  of  the  system  includes  the  set  of  time-servers  {T<(t)}.  Let 
Ti(t)  =  To  be  the  set  of  system  states  in  which  the  readout  of  time-server-*  is  T0.  Hence, 
we  can  define  the  following  predicates  on  system  states.  The  predicate  Taft(T0)  is  true  for 
Ti[t)  >  T0  and  false  otherwise.  The  predicate  Tbef{Ti)  is  true  for  T<(t)  <  T*  and  false 
otherwise. 

Most  of  the  time  service  algorithms  (e.g.  [13])  that  have  been  published  deal  with  two 
major  issues.  The  first  issue,  synchronization  or  ordering  of  events  in  the  system,  may  be 
associated  with  the  past,  in  the  sense  that  its  requirements  are  due  to  events  that  have 
already  occured.  The  major  property  required  in  this  aspect  is  that  any  two  clocks  in  the 
system  must  differ  from  each  other  in  the  lowest  possible  value.  Hence,  when  reasoning 
about  two  events  that  are  related  to  different  local  views  of  the  global  time,  the  proper 
resolution  is  obtained  for  event  ordering.  Thus,  local  histories  that  are  based  on  the 
sequence  of  values  assigned  to  local  variables  and  on  the  sequence  of  local  times  at  which 
these  assignments  took  place2  provide  the  means  to  analyze  the  past.  The  second  issue, 
providing  the  knowledge  of  the  global  (universal)  time,  may  be  associated  with  the  present. 
Here  the  service  is  to  answer  questions  of  the  kind  “what  is  the  time  now?”.  In  that  aspect, 
the  major  property  required  from  each  clock  in  the  system  is  to  be  as  correct  as  possible, 
or  in  other  words  as  close  to  the  global  (universal)  time.  A  third  issue  is  the  way  in  which 
a  time  service  deals  with  projections  onto  the  future.  This  issue  is  of  extreme  importance 
in  hard  real-time  systems,  in  which  some  important  decisions  are  taken  in  accordance  with 
events  that  have  not  occured  yet,  but  are  known  to  occur  in  a  known  time  interval  in  the 
future. 

An  example  is  given  in  Figure  2,  describing  a  temporal  justification  scheme.  The  same 
server  object  is  allocated  to  different  users  at  different  times,  hence  creating  a  user  jus- 

3Namely,  relating  event  counter*  to  in  occurrence  function  while  tatisfying  an  accuracy  axiom  ([23,4]). 


tification  for  this  object  at  different  time  intervals.  These  intervals  are  in  the  future  and 
according  to  them  real-time  scheduling  decisions  are  to  be  taken.  A  very  important  issue 
arises  in  the  above  justification  scheme.  The  time  according  to  which  the  decisions  are 
taken  is  a  local  and  imprecise  view  of  the  global  time.  Distributed  computations  may  have 
the  same  local  view  at  different  nodes  at  different  “real11  times.  Therefore,  future  projec¬ 
tion  of  time  should  avoid  ambiguities  and  conflicts  that  originate  in  differences  between 
local  views. 

This  future  projection  issue  is  expanded  in  section  3.1  of  this  paper,  but  in  order  to 
have  a  better  understanding  of  the  needs,  we  first  explain  the  way  in  which  a  guarantee  to 
meet  a  deadline  is  examined  in  a  real-time  system. 

1.3  Guarantees  in  Hard  Real-Time  Systems 

When  a  request  for  a  specific  object  invocation  arrives  at  a  hard  real-time  reactive  operating 
system,  the  operating  system  has  to  allocate  (in  cases  where  it  is  feasible)  all  the  resources 
required  such  that  it  is  guaranteed  that  the  object’s  time  constraint  is  met.  Informally 
speaking,  a  time  constraint  is  a  requirement  to  start  executing  a  particular  executable 
object,  after  a  condition  is  satisfied,  and  complete  the  execution  before  its  deadline.  The 
execution  time  of  the  object  is  assumed  to  be  given,  and  the  constraint  is  extended  to  a 
periodic  execution  of  the  object.  We  have  defined  a  time  constraint  formally  in  [15,16]  as 
the  quintuple 

<  Id, Taft{conditioni),cii,  fid, Tbcf{conditioni)  > 

where: 

Id  is  the  name  of  the  executable  object  (process)  in  the  proper  context, 

Taft(conditioni)  states  after  what  event  should  execution  begin.  Simple  true  stands  for 
“as  soon  as  possible” , 

cjd  is  the  computation  time  of  object  Id, 

fid  is  the  frequency  with  which  the  computation  should  be  carried  out  in  case  this  is  a 
periodic  process.  In  case  of  a  spontaneous  (sporadic)  process,  this  is  the  maximal 
frequency  expected,  fu  =  0  stands  for  a  single  occurence  of  execution, 

The f  {condition^)  states  the  deadline  du  —  Td  —  Now  which  should  be  met.  condition a  = 
Tu{t)  =  Td  with  Td  =  oo  stands  for  an  “off  line”  computation. 

The  time  interval  defined  by  the  events  Taft{condition\ )  and  Tbcf{conditioni)  delimits 
the  domain  in  which  the  executable  object  is  allowed  to  execute. 


A  real-time  reactive  operating  system  uses  the  time  constraint  as  the  key  to  its  decisions 
on  execution  initiation  and  resource  scheduling  ([18]).  Before  execution  initiation,  the 
allocation  and  context  initialization  are  required  to  ensure  schedulability  of  an  accepted 
job.  These  tasks  are  carried  out  by: 

•  an  off-line  allocator /binder  that  manages  the  acceptance  of  jobs  (requests  to  execute 
objects),  the  name  binding  and  the  allocation  of  the  resources  before  loading,  and 

•  an  on-line  loader  that  activates  schedulable  objects  that  are  invoked. 

In  between  the  binding  and  the  loading,  a  positive  verification  of  the  schedulability  of 
the  invoked  object,  according  to  its  time  constraint,  is  to  be  verified.  All  the  required 
resources  should  be  allocated  and  reserved  for  the  object,  assuring  that  it  is  going  to  meet 
its  deadline.  It  is  not  only  processors  that  are  to  be  allocated  for  an  object.  An  object  may 
rely  on  other  server  objects  in  order  to  perform  its  functions.  These  other  objects  may 
or  may  not  reside  at  the  same  site.  Remote  services  necessitate  the  needs  for  agents  and 
for  communication,  each  of  which  has  to  be  schedulable  within  the  time  constraints  of  the 
invoked  object.  One  must  take  into  account  that  time  constraints  are  projected  between 
different  computation  localities,  such  that  each  computation  locality  might  have  access  to 
a  different  clock  with  a  different  accuracy  and  correctness.  This  projection  is  discussed  in 
details  in  section  3.1. 

The  scheduling  is  also  carried  out  in  two  parts. 

•  An  off-line  scheduler  process  manages  the  policy  of  a  scheduling  discipline.  For  exam¬ 
ple,  when  a  resource  is  added  to  the  system,  in  addition  to  recognizing  the  availability 
of  that  resource,  a  new  discipline  may  be  required. 

•  An  on-line  scheduler  applies  the  current  discipline. 

Another  major  issue  is  the  question  of  users  sharing  a  server  object,  without  violating 
the  user  objects’  time  constraints.  Each  server  object  is  then  considered  as  a  resource, 
and  maintains  its  own  schedule.  When  a  server  is  allocated  to  a  new  user,  and  the  binder 
updates  the  justification  links,  the  server’s  future  schedule  is  to  be  checked  to  show  schedu¬ 
lability  within  the  new  user’s  time  constraints,  without  violating  the  services  this  server 
has  already  guaranteed  to  serve. 

2  Notations 

Having  defined  the  system,  we  now  introduce  some  tools  with  which  temporal  properties 
and  relations  can  be  expressed  and  analyzed. 


2.1  Time  Representation 

The  representation  of  time  has  been  widely  examined  for  purposes  that  vary  from  reasoning 
on  planning  in  artificial  intelligence  to  accurate  scheduling  in  real-time  operating  systems. 
The  characteristics  we  require  from  the  representation  to  fit  for  reasoning  about  time,  both 
for  allocation  (or  planning)  and  for  scheduling,  are  given  below. 

1.  The  representation  of  time  should  allow  representing  instantaneous  events,  expressing 
dates  or  time  points. 

2.  It  should  allow  representing  events  with  durations,  expressing  named  periods  or  time 
intervals. 

3.  It  should  suuport  description  of  events  whose  duration  may  be  convex  (contiguous)  or 
non- convex  (containing  gaps).  Particularly,  it  should  support  representation  of  both 
periodic  and  sporadic  non-convex  event  durations. 

4.  It  should  allow  reasoning  about  a  variety  of  temporal  ordering  relations. 

5.  It  should  support  different  granularity  levels,  allowing  the  resolution  to  vary  according 
to  the  reasoning  needs. 

6.  It  should  support  relative  as  well  as  absolute  quantifications. 

2.2  Intervals  Versus  Points 

The  literature  on  time  representation  contains  a  long  and  conflicting  debate,  full  of  contra¬ 
dictory  theories,  between  those  who  are  in  favour  of  a  time  point  based  representation,  and 
those  who  are  in  favour  of  a  time  interval  based  representation.  J.  Allen  (in  [l])  has  empha¬ 
sized  a  major  disadvantage  of  the  time  point  representation  of  events.  Since  instantaneous 
events  are  not  decomposable,  time  point  events  cannot  be  decomposed  into  subevents  while 
maintaining  an  ordering.  Furthermore,  an  event  which  seems  to  be  instantaneous  in  one 
scope,  may  be  decomposable  in  another  scope. 

On  the  other  hand,  using  only  intervals  might  allow  a  cumulative  loss  of  time  under 
some  circumstances.  For  example,  consider  the  operation  of  setting  an  interval  timer  by 
a  “store”  operation  ([25]).  The  time  from  the  clock  interrupt  to  the  actual  store  is  lost. 
The  above  problem  is  usually  solved  by  replacing  the  “store”  by  an  “add*.  The  overhead 
of  clock  update  and  the  overhead  of  checking  the  task  table  after  each  interrupt  constitute 
a  lower  bound  on  the  clock  granularity  as  well. 

Yet,  one  should  recall  the  fact  that  an  interval  can  be  represented  by  its  endpoints. 
Therefore,  allowing  both  points  and  intervals,  along  with  allowing  the  granularity  to  vary, 
solve  the  above  problems. 


A  real-time  system  needs  both  time  interval  and  time  point  representations.  The  way  in 
which  a  time  constraint  is  defined  in  section  1.3  emphasizes  it.  Reasoning  about  a  deadline 
requires  absolute  and  relative  time  point  representations.  Considering  and  projecting  the 
Tbef  and  Taft  conditions,  as  well  as  the  computation  requirements,  obviously  requires 
time  interval  representations.  The  possibility  of  periodic  time  constraints  extends  the 
needs  further  to  non-convex  intervals  ([9,10]),  each  of  which  might  contain  gaps. 

2.3  Temporal  Relations 
2.8.1  Basic  Definitions 

The  following  definitions  concern  the  entities  with  which  we  are  going  to  reason  about 
time,  namely  time  points  and  time  intervals. 

Definition  1  A  time  point  is  a  real  number  that  represents  the  occurrence  time  of  an 
instantaneous  event,  and  is  an  indivisible  entity.  □ 

The  order  of  two  time  points  is  defined  if  and  only  if  the  two  time  points  are  expressed 
with  respect  to  the  same  reference  frame.  Let  ta  and  tp  be  such  time  points. 

Definition  2  Two  binary  relations  are  defined  for  time  points. 

•  ta  <  Ip  (ta  before  tp )  and  its  inverse  ta  >  tp  (ta  after  tp ). 

•  ta  =  tp.  □ 

Definition  3  A  convex  time  interval  is  a  contiguous  period  of  time  that  specifies  a  rage 
of  time  points  such  that 

<ta,tp  >={t:t^<t<tp).D 

The  above  definition  implies  that  a  time  point  ta  can  be  associated  with  the  time  interval 
<  ta,ta  >. 

Definition  4  The  duration  of  a  convex  time  interval  <ta,tp>  is  a  measure  of  the  interval 
such  that 

II  ^  ta,tp  >  ||  =  \tp  —  tc  I .  □ 

Definition  5  A  non-convex  time  interval  is  a  set  of  subintervals  expressed  as  an  union  of 
disjoint  convex  intervals.  □ 

The  last  definition  means  that  unlike  a  convex  interval,  which  is  contiguous,  a  non- 
convex  interval  might  contain  gaps. 
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Figure  3:  Convex  Interval  Binary  Relations 
2.S.2  Convex  Interval  Relations 

A  set  of  thirteen  binary  relations  between  convex  intervals  is  proposed  in  [l]: 

•  equal, 

•  precced  and  its  inverse  succeed, 

•  meet  and  its  inverse  met-by, 

•  overlap  and  its  inverse  overlapped-by, 

•  start  and  its  inverse  started-by, 

•  during  and  its  inverse  contain, 

•  end  and  its  inverse  ended-by. 

The  relation  disjoint  (txj)  can  therefore  be  expressed  as 

A  m  B  =  (A  •<  B)  V  (A  y  B), 


raws; 


and  all  the  containment  possibilities  as 

[A  T  B)  v  (A  c  B)  v  {A  |  B). 

Equivalently,  these  relations  can  be  defined  based  on  the  intervals’  endpoints.  A  sum¬ 
mary  of  these  relations  is  given  in  Figure  3,  using  some  notations  borrowed  from  [9].  In  [2], 
it  is  shown  that  one  primitive,  meet,  is  sufficient  for  constructing  all  the  other  relations. 

2.3.8  Nan-Convex  Interval  Relation* 

Our  need  to  extend  the  relations  of  convex  intervals  to  non-convex  intervals,  originates 
in  the  definition  of  a  time  constraint  as  given  in  section  1.3.  Having  a  constraint  whose 
frequency  is  lower  than  the  reciprocal  of  the  computation  time,  is  directly  modelled  by 
a  non-convex  interval.  In  Definition  5  above,  we  defined  a  non-convex  time  interval  by 
means  of  an  operator  applied  to  convex  time  intervals.  In  the  following  definitions  let  A 
and  B  be  convex  time  intervals,  such  that 

A  =<  t£,tf  >,B  =<  tf  ,tj  >  . 

We  now  define  the  application  of  some  operators  on  these  time  intervals. 

Definition  6  The  interval  intersection  of  convex  time  intervals  A  and  B  is  defined 
for  -i(A  -<  B)  A  -i(A  >~  B)  as 

Ar\B=<  max(f2,t£),min(*2,tf )  > 
and  is  defined  <f>  (null)  for  {A  -<  B)  V  [A  >■  B).  □ 

Note  that  from  the  above  definition,  the  intersection  of  two  convex  intervals  that  meet 
each  other  is  a  non-null  convex  interval  of  duration  zero,  or  in  other  words  a  time  point. 

Definition  7  The  cover  ([14])  of  convex  time  intervals  A  and  B  is  a  convex  interval 
defined  as 

A  W  B  =<  mm(t£,ti]),max(tf,tf)  >  .□ 

The  cover  is  a  symmetric  and  commutative  operation,  a  property  that  allows  defining  the 
operation  on  a  set  of  more  than  two  intervals 

n 

1+)  {Cj}  =  Ci  W  Cj  W  Cj  W  •  •  •  W  cn. 
i=l 

Definition  8  The  set  of  maximal  convex  subintervals  of  convex  time  intervals  A  and  B 
is  defined  as  $({A},{£}),  such  that 


•  AHB  =  <f>=>  S  =  {A,H} 

•  AnB  S  =  {AUB). 


The  set  of  maximal  convex  subintervals  of  a  non- convex  time  interval  D  is  the  set  of 
maximal  convex  subintervala  of  all  its  convex  members  {d,}.  □ 


Definition  0  The  set  union  of  non-convex  time  intervals  C  and  D  is  a  non- convex  interval 
which  consists  of  the  set  of  members  in  S  ({C})  and  the  set  of  members  in  S  ({D}) 


{C}u{D}  =  S{{C})u  $({£}).□ 


Note  that  the  cover  of  the  set  union 


(+|({C}  U  {£>})  =<  min(i£ ,£),max(tj\t£)  > 


The  union  is  a  symmetric  and  commutative  operation,  a  property  that  allows  defining 
the  operation  on  a  set  of  more  than  two  intervals 


U(-)  =  Ci  U  Cj  U  Cj  U  •  •  •  U  cn. 


Definition  10  The  interval  union  of  non-convex  time  intervals  C  and  D  is  a  non-convex 
interval  E,  denoted 

E  =  CUD, 

such  that 

E=  5({C}U  {£>}).□ 


Note  that  the  cover  of  the  interval  union  equals  the  cover  of  the  set  union,  and  that  the 
interval  union  is  commutative  too.  Hence, 


LK«>  =  Ci  U  Cj  U  Cj  U  •  •  •  U  cn. 

1=1 


Applying  generalization  to  the  above  convex  interval  relations,  results  in  non-convex 
interval  relations  as  described  below.  Let  C  and  D  be  non-convex  intervals,  and  let  {c,-} 
and  {4}  be  their  corresponding  sets  of  maximal  convex  subintervals.  Let  #  and  Q  be 
convex  relations  defined  in  section  2.3.2. 


•  mostly.  C  mostly-#  D  if 


Vd,-  €  D  :  3c,'  €  C  :  c,#d,. 


V>VV! 


•  always:  C  always- £  D  if  and  only  if  C  mostly- Z  D  and  D  mostly- Zu  C,  where  Zu  is 
the  converse  relation  to  Z. 

•  partially:  C  partially-  Z  D  if  and  only  if 

X={xi}  =  {ei,di:eiZdi}^<i>, 

{C-X}n{D-x}  =  4>. 

•  sometimes.  C  sometimes-  Z  D  if  and  only  if 

X  =  {xi}  =  {ei,di:eiZdi}jL<f>. 

•  disjunction:  C  Z  V  ...  V  £  D  if  and  only  if 

Vc<  €  C, Vdj  €  D  :  aZdj  V ...  V  CiQdj  V  c,  ix  d,-. 

•  totally.  C  totally-#  D  if  and  only  if 

Vdy  €  D  :  Vc<  €  C  :  CiZdj. 

For  example,  the  non-convex  intervals  disjoint  (£T)  relation,  that  can  be  expressed  as 
“totally-tx”,  meaning 

Vdy  €  D  :  Vc,-  6  C  :cj  m  dj. 

Further  discussion  on  generalization  of  convex  interval  relations  to  non-convex  interval 
relations  and  additional  non-convex  interval  relations  that  are  based  on  the  leftmost  and 
rightmost  convex  subintervals  of  non-convex  intervals  are  provided  in  Appendix  A.  The 
leftmost  convex  subinterval  of  C  is  denoted  <C  and  the  rightmost  one  >C. 

3  Schedulability 

The  above  temporal  relations  serve  as  a  basis  for  reasoning  about  scheduling.  In  this 
section  we  phrase  conditions  and  propose  mechanisms  for  a  policy  of  accepting  requests 
for  invocations  of  objects  (or  resources),  while  guaranteeing  that  a  deadline  of  an  accepted 
request  will  be  satisfied.  An  invocation  of  an  object  contains  three  phases  of  scheduling 
activities.  In  the  first,  the  incoming  time  constraint  is  verified  to  be  schedulable.  In  the 
second,  the  requesting  user  object  chooses  the  computation  localities  for  execution,  from 
those  where  schedulability  has  been  confirmed.  In  the  third  phase,  an  on-line  selection 
and  context  switching  is  carried  out.  Some  operating  systems,  e.g.  CHAOS  [20,21],  merge 
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Figure  4:  Time  Constraint  Laxity  “Window* 

the  second  and  third  phases  into  one.  We  find  it  very  expensive  to  choose  computation 
localities  upon  each  context  switching,  and  maintain  three  phases3.  The  first  phase  is 
carried  out  by  an  off-line  allocator ,  the  second  by  an  on-line  loader ,  and  the  third  by  an 
on-line  scheduler. 

3.1  Constraints  Propagation 

In  section  1.3  we  defined  the  system  time  constraints  as 

<  Id,Taft{conditioni),cjd,  fid, Tbtf  (condition})  >  . 

The  conditions  imposed  on  beginning,  Taft(condition\ ),  and  on  end,  Tbcf  (condition.}), 
create  a  time  window  whose  duration  must  be  at  least  C/j.  Generally  this  window  is  wider, 
such  that  upon  execution  there  are  more  than  one  possibility  that  satisfy  the  constraint, 
creating  a  definable  laxity  of  that  constraint. 

In  [19],  each  time  constraint  is  considered  as  a  set  of  possible  occurrences  (SOPO),  a 
domain  in  which  the  beginning,  the  end  and  the  duration  are  constrained.  A  simple  set  of 
possible  occurrences,  when  expressed  graphically  on  begin-end  axes  as  in  Figure  4,  creates 
a  “window”  of  the  constraint  laxity.  The  diagonal  axis,  t,  satisfies  begin  =  end,  or  in  other 
words  represents  the  locus  of  dates.  Obviously,  the  occurrences  are  confined  to  the  area 
above  the  diagonal  t  axis,  since  end  >  begin  for  nonzero  duration.  Each  point  within  the 
window  satisfies  the  given  time  constraint:  it  starts  after  the  earliest  and  before  the  latest 
begin  time,  it  ends  after  the  earliest  and  before  the  latest  end  time,  and  its  duration  varies 
from  the  minimal  to  the  maximal  duration  time. 


Figure  5:  Time  Constraint  Propagation 


When  we  have  more  than  one  constraint,  the  temporal  relations  between  the  constraints 
dictates  the  way  in  which  constraints  are  propagated.  Adhering  to  the  notation  of  [19], 
we  can  examine  the  way  in  which  a  time  constraint  TC\  is  propagated  onto  another  time 
constraint  TC* ,  as  described  in  Figure  5.  Recall  that  each  point  in  the  “window”  of  each 
time  constraint  stands  for  a  possible  occurrence  with  the  appropriate  (begin,  end)  point 
coordinates.  Projecting  the  latest  possible  end(TC{)  onto  the  begin  axis  of  TCj,  creates 
a  window  of  occurrences,  denoted  A,  whose  points  stand  for  occurrences  for  which  the 
relation  TC\  <  TCj  definitely  holds.  Projecting  the  earliest  possible  begin(TC\)  onto  the 
end  axis  of  TCj,  creates  the  section  B,  for  which  TCj  -<  TCi  definitely  holds.  Section  C  is 
characterized  with 

( begin(TCt)  <  end^TCi ) )  A  ( end(TCt)  >  endma«(TC1) ). 

In  other  words,  TC\  l~l  TCj  is  definitely  non-null  in  section  C.  The  two  streaked  areas  in 
Figure  5  show  regions  in  which  the  temporal  relation  between  the  time  constraints  is  not 
certain.  In  this  regions  the  relation  can  be  determined  only  upon  an  accurate  knowledge 
of  the  actual  (begin,  end)  point. 

The  above  method  of  constraint  propagation  has  been  demonstrated  for  a  convex  time 
constraint  with  relation  to  another  convex  time  constraint.  When  a  relation  is  required 


between  TCi  and  TCj,  then  TCi  kij  TCj  is  achieved  if  we  intersect  TCj  with  the  region 
allowed  by  TCi  and  Zij.  Algorithms  for  propagation  of  convex  constraints  have  been 
suggested  for  temporal  reasoning  purposes  as  well  as  for  scheduling  purposes,  as  in  [1,24,19]. 

Extending  the  method  for  finite  non-convex  time  intervals  can  be  easily  done  for  re* 
lations  which  are  generated  by  application  of  generalisation  functors  on  convex  relations. 
However,  periodic  time  constraints,  which  consist  of  finite  convex  subintervals,  yet  are  not 
finite  non-convex  intervals,  are  fairly  difficult  to  be  dealt  with  in  this  method.  One  possi¬ 
ble  simplification  is  the  “local"  solution,  in  which  relations  are  derived  and  constraints  are 
propagated  only  within  a  limited  region,  using  the  above  methods.  This  solution  solves 
many  problems  in  which  there  is  no  need  to  reason  about  two  constraints  which  are  far 
apart  from  each  other,  as  in  our  case. 

Another  propagation  issue  that  is  to  be  dealt  with  is  the  correct  mapping  of  a  constraint 
and  its  synchronized  interpretation  at  different  computation  nodes.  Being  served  by  dif¬ 
ferent  clock  servers  means  having  different  interpretations  for  an  imposed  time  constraint. 
We  assume  that  the  time  servers  use  a  linear  interpretation  of  the  following  type.  The 
service  for  a  get-time  request  is 

T,  M  =  M1)C,(<)  +  MO ,  <  >  f<”» 

as  defined  in  section  1.2.  The  bounds  on  the  correct  knowledge  of  a,(t)  and  bp(t)  set  the 
scale  in  which  a  projection  of  a  time  constraint  is  propagated.  The  projection  scale  must 
ensure  that  no  violation  of  the  constraint  will  occur  due  to  the  projection. 

Let  Aa,,  =  max  |1  —  ap(endmaa(TCi))\  and  let  A bp  =  max  | bp (endmax (TC,- ) ) | .  Let  Say  = 
max|l  -  a,, {begirinin (TCi)) |  and  let  6bp  =  max  |6p(&e0»nmin(T<7i))|.  Accordingly,  at  a 
computation  node  p  an  imposed  time  constraint  TCi  maps  to  the  local  bounds: 

tegin'niJTCi)  =  beginmin(TCi)  +  Sopbegin^^TCi)  +  6bp , 

tegin'm-iTCi)  =  begirinatiTCi)  -  Sopbegin^iTCi)  -  6bp, 
en^min(TCi)  =  endninpCi)  +  Aapend^^TCi)  +  Aft,, 
en<^ma,(TCi)  =  endmamiTCi)  -  A OpCnd^iTCi)  -  A  V 

The  laxity  is  reduced,  but  no  violation  of  the  constraint  can  happen  due  to  clock  inaccu¬ 
racies. 

In  the  rest  of  this  paper  we  implicitly  assume  that  the  above  mapping  is  applied  to 
every  incoming  time  constraint  before  accepting  it. 


S.2  Allocation  and  Scheduling  Orientation 

For  allocation  verification  purposes  and  for  scheduling  purposes,  we  may  decrease  the 
degree  of  generality,  that  has  been  defined  in  the  previous  section,  by  considering  only  the 
maximal  durations  of  the  constraints.  The  reason  of  decreasing  the  generality,  which  has 
been  increased  primarily  for  temporal  reasoning  purposes,  is  that  for  verification  of  the 
schedulability  of  a  new  object  one  needs  to  assume  the  worst  case  in  order  to  be  able  to 
guarantee  future  execution.  Considering  the  possible  allocations  shows  that  the  worst  case 
means  maximal  time  consumption  by  the  already  accepted  objects. 

Let  the  j’th  occurrence  of  time  constraint  i  be  denoted  as  TC*f\  represented  as  the  j’th 
maximal  convex  subinterval  of  non-convex  interval  TC,.  Let  P/^  be  a  convex  interval,  for 
which 

(P<0)  t  TCp])  V  (P,w  c  TCP)  V  (P«w  i  TCP). 

The  definition  of  a  time  constraint  in  section  1.3  can  therefore  be  converted  as  follows. 

•  Taft(eonditioni)4  — ►  begins*  (TC^) . 

•  Tbe  f  (condition^)6  — ►  endn^TC^). 

•  fi  periodicity  — ►  Vj  >  1 :  emkw^rC^)  -  endmaa(TCf,~ =  j-{. 

•  a  computation  time  — ►  Vj'  >  1  :  ||P/^||  =  c,-. 

The  fact  that  the  duration  of  P^  might  be  less  than  that  of  TC^  requires  a  more  precise 
definition  regarding  the  degree  of  freedom  we  have  in  moving  P/^  within  the  TC ^  window. 

Definition  11  The  laxity  of  a  (computation)  convex  interval  P/^  that  is  constrained 
within  a  (window)  convex  interval  TC\ ^  is  defined  by  the  pair  (backwardjBlack,forwardjslack). 
If  no  other  constraint  is  imposed,  then 

backward-slack  =  x_  =  -  t*c, 

forward-slack  =  x+  =  tTpc  - 1%. 

Imposition  of  additional  constraints  that  affect  the  TC\ ^  window  should  be  considered  when 
the  laxity  is  derived.  □ 

4B«cin  filter. 

*DMdUM. 


Let  TCin  be  a  time  constraint  whose  schedulability  is  to  be  tested.  Let  all  the  other 
already  accepted  time  constraints,  TC}*\  be  schedulable.  We  first  consider  the  case  of 
a  single-occurrence  time  constraint  with  a  contiguous  computation  requirement  (hence 
convex),  and  then  we  analyze  the  bounds  that  guarantee  schedulability  of  a  non-convex 
time  constraint. 

S.2.1  Convex  Time  Constraints 

A  single-occurrence  time  constraint  has  a  known  window  where  it  might  occur: 

TCin  =<  bcgtrijfun^T Cin) t e>tdmaa(rCin)  >  . 

In  this  window  one  must  verify  that  after  satisfying  the  already  accepted  time  constraints 
one  can  schedule  a  convex  subinterval  of  duration  ||Pin||  which  is  contained  within  TCin. 
The  already  accepted  time  constraints  are  assumed  schedulable  already.  From  these  al¬ 
ready  accepted  time  constraints  construct  a  set  of  maximal  convex  subintervals,  which  are 
checked  according  to  our  verification  interval 

V  =<  £,tj  >  . 

Initially,  V  =  TC{„  =<  6efftnm,„(TCi„), endm4«(rC',n)  >.  Each  subinterval  that  intersects 
with  V,  denoted  TC}*\  has  one  of  four  possible  relations  with  it. 

1.  TC\’]  0  V,  or 

2.  (TC^  t  V)  V  {TC\i]  <  V)  V  {TC\j)  i  V ),  or 

3.  TC^  0“  V,  or 

4.  (TCjJ)  T“  V")  V  (TCP  >  V)  V  (TC},)  V). 

Let  the  set  of  all  the  above  interfering  maximal  convex  subintervals  be  the  interfering  set, 
denoted  I.  Let  I\  be  the  subset  of  those  that  overlap  V,  Is  the  subset  of  those  that  are 
overlapped  by  V ,  J3  the  subset  of  those  that  are  within  V,  and  J4  the  subset  of  those 
containing  V.  If  I*  is  empty,  then  we  verify  directly  according  to  the  boundaries  of  TC,„. 
Otherwise,  we  extend  the  verification  boundaries  to  those  of  a  member  of  I4  which  is  not 
contained  within  any  other  member  of  J4.  This  extension  requires  appropriate  extensions 
of  Ji,  Is  and  Is-  Each  of  the  members  of  J4  is  moved  to  the  appropriate  subset  as  well. 
The  constraint  which  sets  the  boundaries  of  V  is  of  course  in  Jj.  For  worst  case  analysis 
we  consider  an  artificial  case  in  which 

TCjj)  €  h  :  PjJ)  i  TCjj) 


S  .V‘«\  .V 


V  V 


y^(/) 

setting  x+  *  «—  0,  and 

TC&  e  Js  :  T  TCp] 

setting  x_  '  «—  0.  Doing  so,  we  encounter  the  largest  computation  requirement  possible 
within  the  verification  window. 

We  can  now  create  two  new  subsets  If  and  If,  for  which  only  the  relevant  portions  of 
overlapping  time  constraints  are  accounted  for. 

X,*  s  {rcg*>  }  =  {  <  m*x(btlinmt„[TcP),tr'),en<L..(Tcll))  > ,  TC,01  s  X,} 

IS  s  {  TC«->  }  =  {  <  ieiin^TCP), min(lj,  emC,I(TC,!<1) )  >  ,  rcf>  €  Xj} 

For  each  of  the  subintervale  in  and  Xs°  the  computation  requirement  P<  is  appropriately 

set  to 

||P(«-'||=min(||P((i>«,||rcW||). 

Hence,  we  can  formalize  the  condition  for  schedulability  for  both  preemptive  and  non- 
preemptive  schedulers. 

Condition  1  TCin  ia  non-preemptively  schedulable  if 

VtVj  :  TC\i]  €  1°  :  3x1°?  >  0. 3x+^  >  0. 3xlc<»  >  0.  3x™«  >  0.  : 

Pin  *  P}j) 

where  1 0  ia  the  aet  union  of  If,  I3  and  If.  In  other  worda, 

{Pin}&P° 

where  P°  ia  the  aet  {P}i]  :  TC^  el0}.  □ 

An  example  of  such  a  verification,  which  obeys  Condition  1  is  given  in  Figure  6.  The 
verification  interval  (V)  is  TCi„,  because  I4  is  empty,  h  contains  one  convex  subinterval 
of  TC i,  1$  contains  one  convex  subinterval  of  TC$  and  Jj  contains  two  convex  subintervals 
of  TC%.  As  can  be  seen  in  this  example,  Pin  demonstrates  non-preemptive  schedulability, 
since  it  is  disjoint  from  the  disjoint  occurrences  of  the  relevant  P/^’s  (*=1,2,3). 

The  totally-disjoint  (St)  requirement  can  hold  either  if  the  computation  interval  Pin  is 
disjoint  in  its  original  placement,  or  if  TC{„  has  enough  laxity  to  allow  a  new  placement  of 
Pin  to  give  a  disjoint  relation.  The  time  constraints  of  1°  that  have  either  overlapping  or 
containment  relations  with  TC<n,  affect  its  laxity.  However,  their  own  laxities  are  affected 


Taft  filter 


Tbef  deadline 


Figure  6:  Verification  of  Schedolability  of  TCin 


by  TCin  well.  Figure  7  demonstrates  a  case  of  two  overlapping  constraints,  TCA  0  TCb, 
whose  laxities  allow  the  disjoint  relations.  The  effects  on  the  laxities  are  as  follows. 


=  min(  x?,min(  -  (tjx  -  xt) ) ), 


since  Pb  is  constrained  by  PA  from  the  left.  If  z'®  is  negative,  and  Pb  can  be  moved  to 
the  right  (on  x^’s  account),  the  disjoint  relation  still  holds.  This  requires 

x'f  +  x®  >  0. 

However,  PA  is  constrained  by  Pb  from  the  right.  Hence, 

*+  =  min(  z*,min(  t™4  -  t%4,  (t£B  +  x®)  -  tpp4  ) ). 

Here  again,  a  negative  x4  still  produces  the  disjoint  relation,  by  moving  PA  to  the  left,  if 


x4  ■+■  xt.  >  0. 

In  a  preemptive  schedule  the  condition  can  be  less  demanding,  in  the  sense  that  the 
interval  allocated  for  TC,n  does  not  have  to  satisfy  convexity,  and  therefore  only  duration 
constraints  must  be  imposed.  In  order  to  analyze  the  requirements,  we  examine  two  time 
constraints  TCA  and  TCb >  that  contain  computation  requirements  PA  and  Pb  respectively. 


If  the  context  swiching  can  be  regarded  as  negligible,  then  one  can  allocate  a  resource 
portion  {'IaSIb)  per  time  unit  during  the  time  intervals  TCa  and  TCb  respectively,  such 
that 

,  =J5*L<, 

7A  nrc*#  - 

_  lift!  ... 

18  #rc«#  - 

and  still  satisfy  the  requirements.  In  other  words,  satisfication  is  due  to 


L’udt=p* 


and  respectively  for  Pb- 

Yet,  when  two  or  more  constraints  are  not  disjoint,  one  must  satisfy  an  additional 
constraint.  Resource  portions  cannot  be  allocated  in  a  manner  that  excedes  a  unity  for  a 
single  resource.  In  other  words,  in  all  possible  instances  of  resource  requirement  intersection 
the  following  may  be  asked  to  hold. 

7a  +  If  bH - <1 

However,  this  requirement  is  too  strong  for  the  following  reasons.  First,  the  assumption 
that  the  resource  portion  is  a  constant  is  not  necessary.  Second,  even  for  a  non-constant 


to 


'y(f)  the  convexity  assumption  is  not  necessary,  since  we  allow  preemption.  Therefore,  a 
resonable  condition  can  be  derived  by  checking  that  for  intersecting  requirement  intervals 
a  single  resource  (or  the  inventory  in  the  multiple  resource  bank  case)  has  the  “capacity” 
to  respond.  For  intersecting  TCa,TCb,  and  others,  it  can  be  formulated  as 

f  TU( 0  dt  +  j  7b(0  di  H - -  ||Pb||  +  ||Ps||  H - <  || TCA  U  TCb  U  •  •  •  ||. 

JTCa  JTCm 

Recalling  the  definition  of  the  set  of  maximal  convex  subintervals6,  the  condition  we  impose 
for  accepting  a  time  constraint  TCin  is  given  below. 

Condition  2  Let  V  be  the  verification  interval,  derived  from  the  duration  of  a  time  con¬ 
straint  TCU,  for  which  TC «  =  TC,n  or  TCt  »  rC,n.  Let  ly  be 

Jv  =  I°U{TCin}-{TCa} 

where  1°  is  the  set  union  of  If,  Jj  and  If. 

TCin  w  preemptively  schedulable  if 

Vs,  €  S(Iy)  :  £  ||s,np||  <  ||s„|| 

Vt:TC<€7v 

A 

E  N«.ll  <  imi  -  IIAII 

V..€S(/v) 

where  a„  are  the  convex  subintervals  of  S{Iy).  □ 

An  algorithm  for  verification  of  the  schedulability  of  a  convex  constraint  is  proposed  in 
section  3.3.1,  based  on  the  above  conditions.  The  properties  of  that  algorithm  are  discussed 
in  section  4. 

8.2.2  Nan-convex  Time  Constraints 

In  real  systems,  time  constraints  might  have  some  arbitrary  precedence  relations  between 
them.  Grouping  them  into  one  time  constraint,  while  forcing  their  execution  to  be  carried 
out  in  a  particular  computation  node  ([5]),  imposes  a  non-convex  resource  requirement  on 
that  node.  This  non-convex  resource  requirement  is  the  set  of  maximal  convex  subinter¬ 
vals  of  the  group  individual  resource  requirements.  The  time  window  in  which  this  group 
is  allowed  to  execute  is  the  cover  of  the  individual  windows  of  the  group.  The  result  of 


*S*«  Definition!  8  and  10. 


the  grouping  is  therefore  a  non-convex  time  constraint.  That  fact  is  a  good  motivation 
to  extend  the  convex  constraint  schedulability  conditions  to  the  finite  non-convex  case. 
Furthermore,  a  resource  requirement  might  be  noncontinuous  to  begin  with.  A  better  uti¬ 
lisation  of  the  resource  is  expected  if  it  can  be  released  in  the  gaps  between  the  subintervals 
in  which  it  is  needed,  without  conflicting  these  subintervals. 

Formally,  a  non-convex  time  constraint  differs  from  a  convex  one  in  the  nature  of  its 
noncontiguous  computation  interval.  For  an  occurrence  window  TC,-  corresponds  a  non- 
convex  computation  interval  Pi  =  Uy  P-*\  such  that 

t  TCi)  V  <  TC()  V  MPM  |  TCt). 

i  i  i 

The  definition  of  laxity  is  slightly  extended  to  include  the  non-convex  nature  of  the  com¬ 
putation  requirement. 


Definition  12  The  laxity  of  a  (computation)  non-convex  interval  Pi  that  is  constrained 
within  a  (window)  convex  interval  TCi  is  defined  by  the  pair  (xZCi,x+Ci),  such  that 

xlc<  <  &■  -  tlc<  =  tf‘  -  tlc\ 


<  t 


TCi 

P 


where  Pf  =  <J  Pi  and  P*  =  >P,.  □. 


tTC{ 

lP 


t*Pi 


If  no  other  constraint  is  imposed  then  the  equality  holds  .  Additional  constraints  that 
intersect  with  TC,-  may  reduce  the  laxity  and  then  the  inequality  holds.  In  case  such  a 
reduction  occurs,  it  is  done  in  the  same  way  it  is  defined  for  a  convex  time  constraint  (and 
illustrated  in  Figure  7),  since  the  laxity  is  defined  above  with  respect  to  |*J  P,,  and  (JP,  is 
convex. 

The  schedulability  is  verified  within  the  time  interval  where  the  computation  is  allowed 
to  occur.  In  this  window  one  must  verify  that  after  satisfying  the  already  accepted  time 
constraints  one  can  satisfy  the  constraint  that  is  to  be  verified. 

The  construction  of  the  interfering  set  is  similar  to  the  process  defined  for  convex  time 
constraints,  since  the  occurrence  window  is  convex  here  too.  Hence,  the  subsets  Jj  to 
are  the  same  in  the  case  of  a  non-convex  time  constraint.  The  worst  case  assumptions  are 
taken  here  too,  but  here  they  are  based  on  non-convex  relations  between  convex  occurrence 
windows  TCi  Mid  their  corresponding  computation  non-convex  intervals  P,-. 

VTCi  €  h  :  Pil{TCi} 
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setting  x™‘  *—  0,  and 

VTCi  e  2S  :  FfiiTCi} 

setting  xZc<  *-  0.  Worst  case  is  expressed  here  by  having  the  largest  computation  re¬ 
quirement  possible  within  the  verification  window,  as  in  the  convex  time  constraint  case. 
Still,  I\  and  2s  include  portions  which  are  outside  the  verification  window.  Therefore,  sub¬ 
sets  which  contain  only  the  portions  of  computation  that  are  in  the  required  verification 
window  are  created. 

i;  =  {  TCi,  }  =  {  <  maxibegirinUniTCi),^  hcnd^iTC,)  >  ,  TCi  €  h} 

I£  =  {  TCit  }  =  {  <  6eytnm,„(TC'<), min(t J ,  endmas(7*C7{) )  >  ,  TCi  €  2S} 

For  each  of  the  subintervals  in  2/  and  2a°  the  non-convex  computation  requirement  Pi  is 
appropriately  set  to 

Pi.  =  {{JP?  I  P<i]  =  P^nTC,.,  p,u)  e  P, }. 

i 

As  in  the  convex  time  constraint  case,  a  basic  assumption  taken  here  is  that  the  already 
accepted  time  constraints  are  already  schedulable.  Based  on  this  assumption  and  on  the 
above  relations  of  the  interfering  set  and  the  verification  window,  we  now  formulate  the 
conditions  for  schedulability  of  a  non-convex  time  constraint. 

First,  for  the  non-preemptive  schedule,  we  require  a  totally-txi  relation  between  all 
the  computations,  as  well  as  avoiding  conflicts  between  windows  of  occurrence  and  their 
corresponding  computation  non-convex  intervals. 

Condition  3  A  time  constraint  with  an  occurrence  window  TCin  and  a  non-convex  com¬ 
putation  requirement  Pin  is  non-preemptively  schedulable  if 

Vi Vj  :  TC\i]  €  1° :  3xlC^  >  0. 3x+C^  >  0.  3x?>  >  0. 3xJ>  >  0.  : 

V/>00  e  p»  .  Pin&'Plp 

where  1°  is  the  set  union  of  1°,  2j  and  2S°  and  P°  is  the  set  {Pjj}  |  TCt- ^  €E  2°}.  □ 

In  the  prteemptive  schedule,  we  now  take  into  account  the  non-convex  nature  of  the 
computation  intervals. 

Condition  4  Let  the  new  constraint  be  a  time  constraint  with  an  occurrence  window  TCin 
and  a  non-convex  computation  requirement  Pin.  Let  V  be  the  verification  interval,  derived 


typedef  struct  convex-timeJnterval  { 
float  start ; 
float  fin ; 

float  referencesccdt ; 
float  reference-bias  ; 

}; 

typedef  struct  time-constraint  { 

struct  convex-timeJnterval  occurrence-window  ; 
float  backward-slack,  forward-slack ; 
struct  convex-timeJuterval  computation-window  ; 
float  frequency ; 
int  state  ; 

struct  time-constraint  *  successor  ; 
struct  timejconstraint  predecessor  ; 

}; 


Figure  8:  Convex  Time  Constraint  Expressed  in  C 

from  the  duration  of  a  time  constraint  TCX,  for  which  TCX  —  TCin  or  TCX  »•  TCin.  Let 

Iv  =  I°U{TCin}-{TCx} 

where  1°  is  the  set  union  of  1°,  J2  and  J30. 

TCin  **  preemptively  schedulable  if 

V«.€i(Ar):  £  E  ll».npf>||  <  IM 

V*:TC,,€/v 

A 

E  IM  <  Ml  -  E  IIA!‘,II 

V*.€$(/y)  VkiP,(i)£P. 

where  sv  are  the  convex  subintervals  of  S(Jy).  □ 

3.3  Scheduling  Feasibility  Verification  Algorithms 


Having  defined  the  conditions  for  schedulability  for  incoming  time  constraints,  one  needs 
to  define  mechanisms  that  provide  the  ability  of  verifying  these  properties.  The  mechanisms 


consist  of  data  structures  and  algorithms.  In  section  1.3  we  have  proposed  a  set  of  modules 
that  perform  the  allocation  of  a  resource  or  an  object.  Upon  a  request  for  allocation,  the 
local  allocator  verifies  the  schedulability  of  the  request  in  the  local  calendar  and  passes  the 
request  to  other  resources  or  objects  if  they  are  needed.  The  knowledge  of  the  resource 
requirements  is  taken  from  the  joint  of  the  invoked  object.  If  the  requests  it  has  passed  are 
confirmed  along  with  a  verification  of  local  schedulability,  it  reserves  the  local  resource. 
The  reservation  is  for  an  a  priori  decided  time,  and  the  requesting  node  must  acknowledge 
the  reservation  within  this  time  by  invoking  the  loader. 

In  the  above  concept  a  calendar  is  a  set  of  accepted  and  reserved  time  constraints.  In 
section  3.2  we  have  shown  an  equivalent  representation  which  is  a  time  interval  based 
representation.  An  example  of  an  implementation  of  such  a  data  structure  is  given  in 
Figure  8. 

Throughout  the  rest  of  this  section  we  propose  two  algorithms  based  on  that  data 
structure  and  on  the  conditions  of  schedulability  proposed  above.  The  first  algorithm,  in 
section  3.3.1,  is  a  boolean  function  that  installs  a  convex  time  constraint  into  a  calendar 
if  its  schedulability  is  verified  according  to  conditions  1  and  2.  The  second  algorithm, 
in  section  3.3.2,  is  an  extension  of  the  first  one  to  install  a  nonconvex  time  constraint 
into  a  calendar  if  its  schedulability  is  verified  according  to  conditions  3  and  4.  Although 
not  explicitly  stated  in  the  algorithm,  the  access  to  the  global  variable  that  represents  the 
current  calendar  must  be  protected  for  mutual  execlusion,  to  avoid  concurrent  accesses  and 
false  deduction.  The  PUSH_TC  boolean  function  we  propose  is  one  of  the  service  access 
points  (SAPs)  of  the  scheduler.  Other  SAPs  might  access  the  same  calendar  concurrently. 
In  the  system  concept  we  proposed  above,  this  mutual  exclusion  mechanism  is  a  part  of 
the  object  access  mechanism  of  the  scheduler  that  is  implemented  in  its  joint. 


S.S.l  Convex  Constraint  Allocation  Algorithm 

type  daw  *  {  preemptive,non- preemptive  }  ; 
type  convex_time_interval=*  construct 

{  begin:  time_point ; 

end:  time-point ; 
scale,  bias:  real  }  ; 
type  timejeonstraint  »  construct 

{  tc:  convex. time  interval ; 

back  slack,  for -flack  :  real  ; 

P  :  convex-time  Jnterval ; 
freq  :  real ; 
state  :  integer  }  ; 

global  var  Already  .Accepted :  set  of  timejeonstraints; 

boolean  function  scbednler.PUSR.TC  (TCln:time^conatraint,  scheduleJype :  class)  ; 


local  var  1°,  Ilt  /a,  I3,  J4,  If,  If,  ly :  set  of  timejeonstraint  ; 

TC\i],TCm,  constraint :  timejeonstraint  ; 

Sy :  set  of  convexjtime Jnterval ; 
v,  a. :  convex-time  Jnterval ; 
i,j,io,3o,k,n:  indices  ; 

/*  Init  •/ 

TCa  -  TCin  ; 

U  ♦-  TCin.tC  j 

/*  Prepare  verification  interval  and  classify  interference  set 
of  already  accepted  time  constraints.  */ 
repeat 

h,h,  h,  I*  1  If  1 1$  *-  4  i 

*  «-0  ; 

V constraint  €  Already -Accepted  Do 

if  constraint,  freq  /  0.  then  Do 

3  *—  |’(u.6ep»n  —  constraint. tc.end)  / constraint. freq]  ; 
TCf3Ktc.begin  *-  constraint. tc. begin  +  j  j  constraint,  freq  ; 
TC\’\tc.end  «—  constraint.tc.end  +  jj constraint. freq  ; 
oD  ; 
else  Do 


constraint ; 


I*  Classification  switch  */ 


while  TCj>]  .tc.begin  <  v.end  Do 

TCj’Ktc  0  v  *=»>  Ii  *—  I\  U  {TCf1}  ; 

(TCf’.te  t  «)  V  (TCj'Ktc  Cv)v  (TC^.tc  i  v)  — >  /3  -  /a  U  {TCjy)}  ; 
T<7<y)  .tc  0-  v  — *  /3  «_  J,  u  {TC|y) }  ; 

(TCj'Ktc  T“  «)  v  (TC4(y).te  »  «)  V  (TCj'Ktc  1“  „)  — ►  /4  «-  /4  U  {TC|y)}  ; 

/*  Next  instance  of  periodic  constraints  */ 
if  conetraint.freq  /  0.  then  Do 
/  «-J  +  l  ; 

TCj  .tc.ispin «—  conetraint.tc.begin-\-  j  /  constraint.  Jreq  ; 
TCf*\tc.end  «—  eonstraint.tc.end+  3 /constraint. freq  j 
oD 

else 

break  ; 

oD; 

*«-»'  + 1 ; 

oD  ; 

if  I4  5*  <k  then  Do 

TCU  «—  maxjconvexjconatraint(It)  ; 
v  *—  max  jconvex  inter  val(I^)  ; 

oD; 

until  /4  =  $  ; 


/*  Update  the  overlapping  already-accepted  constraints  (/i,/s) 

to  contain  only  relevant  portion  within  the  verification  interval.  */ 

V«Vj  :  TC\i]  €  h  :  Do 

TCj^.tc.bepm  «-  max(u. be  jin,  TCf’Ktc. begin)  ; 

TcfyKtc.end «—  TCfJKtc.end ; 

/?-/?u{rc<y->} ; 

oD  ; 

V*Vj  :  TC}J)  €  /,  :  Do 

TCj^.tc.end «—  minfTC-^.tc.end,  v.end)  ; 

TC^  .tc.begin -  TCj})  .tc.begin  ; 

oD  ; 

/°  -  {TCf  > :  (rc|y)  €/?)v  (Tcfy)  €  f2)  V  (TC<y)  €/?)}; 


/*  Check  achedulability  condition  end  accept  if  poeaibk.  */ 

If  schedule  Jype^aon-preemptive  then  Do 
if  ( reeuit  —  VtVj  :  TC^  e  7°  : 

3TC7p) .back-slack  >  0.  A  3TC|y)./or -clock  >  0.  A  3TCin.backjslack  >  0.  A  3TCin.forj>lack  >  0. 

TC^.PhTC^.P)  then 

Air  tody -Accepted  *—  Already-Accepted  U  {TC<„}  ; 
return(reeuit)  ; 

oD  ; 

if  echeduleJype=preemptive  then  Do 

^  -  S(  Jy  «-  J»  U  {TCi*}  -  (TC.) ) ; 

if  ( rceult  «—  Ve,  €  Sy  : 

(V*  :  TCi  €  /y  :  E,  ll-Pt  n  e, II  <  ||e.j|) 

A  (Ell*. II  <  INI -||rC..P||))  then 

Already-Accepted  *—  Already -Accepted  \J  {TC^}  ; 
retnm(reeult)  ; 

oD ; 


S.S.2  Nan-Convex  Constraint  Allocation  Algorithm 

type  class  ■>  {  preemptive, noa-preemptive  }  ; 
type  convex-time-interval**  construct 

{  begin:  time-point ; 

end:  time-point ; 
scale,  bias:  real  }  ; 

type  nonjconvexjtime-interval  —  set  of  convex  .time  interval ; 
type  timejconstraint  *  construct 

{  tc:  convex-time .interval ; 

back-slack,  far_slack  :  real ; 

P  :  nonjconvex-time-interval ; 
freq  :  real ; 
state  :  integer  }  ; 

global  var  Already -Accepted:  set  of  time-constraints; 

boolean  function  scheduler. PUSH-TC  (TC{n:time-constraint,  schedule  Jype:  class) 
local  var  1°,  A,  1 3,  A,  /«,  ,  7J,  hr.  set  of  time-constraint  ; 

P°:  set  of  non  convex  tim»  interval ; 

TCj^ ,  TCm,  constraint:  time-constraint  ; 

Sy:  set  of  convex-time .interval ; 
s,,v:  convex-time  .interval ; 

indices  ; 

/*  Init  •/ 

TC,  -  TCin  ; 
v  *—  TCxn.tc  ; 

/*  Prepare  verification  interval  and  classify  interference  set 
of  already  accepted  time  constraints.  */ 
repeat 

A>  A»  h,  Ai  I3  *—  d  ; 

*  «—  0 ; 

V constraint  €  Already -Accepted  Do 

if  constraint,  freq  0.  then  Do 

3  —  [(v.iepin  —  constraint.tc. end) /constraint. freq]  ; 

TCf.  tc. begin  «—  constraint.tc.begxn  +  3 /constraint. freq  ; 
TCjJKtc.end  *—  constraint. tc.end  +  j / constraint. freq  ; 
oD; 
else  Do 


constraint ; 


(i'Jj'.k1  U'.VJi'.M.H*  »('».*  h'.h'Ji’.h’.h*  •<*  k*  liMi'  ^  t««  iA  fc»  1>'M  i 


/*  Classification  switch  */ 
while  TC^  *.tc.6epin  <  v.end  Do 

TCj”.tc 0»->/,*-Au {TCf*}  ; 

(TCfy).tc  t  v)  V  (TCjy).tc  <v)v  (ref'.ic  {  «)  — *■  /a  «-  /a  U  {TCf  *}  ; 
TCf*.tc  0«  v  -*>  /s  «-  /,  U  {TC(/>}  ; 

(Tcf*.*  t"  v)  V  (TC\y).tc  >«)  V  (TCj'ltc  i*  v)  — »•  I4  «-  /«  U  {TCf*}  ; 
/*  Next  instance  of  periodic  constraints  */ 

If  constraint,  freq  0.  then  Do 
3  «-  3  + 1 ; 

Tcj}Ktc. begin  «—  constraint. tc.begin  +  j / constraint. freq  ; 

TCf  .tc.end  «—  constr'aint.tc.end+ j /constraint,  freq  ; 
oD 


break  ; 

oD  ; 

+  l ; 

oD  ; 

if  U  ft  ^  then  Do 

TC.  <—  maxjconvcxjconstraint(U)  ; 
v  *—  maxjeonvexJnterval(Ii)  ; 

oD  ; 

until  U  —  <f>\ 

/*  Update  the  overlapping  already-accepted  constraints  (/j,  /3) 

to  contain  only  relevant  portion  within  the  verification  interval.  */ 
VtVj  :  ref*  €  h  :  Do 

TCfy“^  .tc.begin  *—  ma x(v.begin,  TCfyKtc. begin)  ; 

TCp'Ktc.end  -  TCj’ltc.end ; 

TC^,]  .for jtlack  «—  0.  ; 

Tcfy,).P  -  TC{ii).PnTcHt).tc ; 

/f  -  U  {ref*1} ; 

oD  ; 

VtVj  :  ref*  €  /s  :  Do 

TC[y*\tc.end  *—  min (TCfJKtc.end,  v.end) ; 

Tcfy,Ktc.begin «—  TCf  * Ktc. begin  j 
TC?‘]  .back  j>lack  -  0.  ; 

rejf  *.p  *-  ref  *.p  n  ref#*.tc ; 

Ij-J?u{ref**}: 

oD; 

p  -  (rejy* :  (ref*  e  /?)  v  (rcj3)  e  /a)  v  (ref*  e  /?) } 
v»vy :  ref  *  e  j°  :  p°  -  u<„,  ref  *.p  ; 
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/*  Check  achednUbility  condition  and  accept  if  poeeible.  */ 

If  ecAedttieJypeamon-preemptive  then  Do 
If  ( result «-  TCim.PG'P° )  then 

Air  eady -Accepted  *—  Already -Accepted  U  { TCin }  ; 

retnrn(reeuit)  ; 

oD  ; 

If  schedule -fype—preemptire  then  Do 

Sir «-  S(k  -ru{TCim)  -  { TC ,}) ; 

If  ( result  *—  Vs,  €  Sir  : 

(Vi  :TCieIv  :'£i Z»:Po»€Pt  II «.  n  p}h) II  <  II..II) 

A(EKII  <  INI- E*ll«h)ID)  then 

Already -Accepted  *—  Already -Accepted  U  {TCiH}  ; 

retnrn(reeuit)  ; 

oDj 

□ 

4  Properties 

We  assume  that  each  of  the  already  accepted  time  constraints  in  the  calendar  have  passed 
successfaly  the  same  schedulability  test.  However,  this  property  is  valuable  only  if  we 
show  that  time  constraints  that  have  been  accepted  after  others,  do  not  contradict  this 
condition  for  the  earlier.  In  order  to  show  the  above,  we  examine  two  possible  cases  that 
might  happen  when  we  accept  a  time  constraint  TC"  after  TC’  has  already  been  accepted. 

1.  TC"  tx)  TC'  :  TC'  is  not  affected  because  there  is  no  intersection  between  the  two 
time  constraints.  The  same  argument  is  valid  for  both  preemptive  and  non-preemptive 
policies. 

2.  TC"  $4  TC‘  :  When  checking  the  feasibility  for  TC ”,  a  portion  of  TC'  n  TC ",  out 
of  TC\  is  assumed  to  consume  its  maximal  resource  requirements  that  it  is  capable 
to  consume  within  the  new  verification  window,  which  is  the  only  domain  that  is 
affected.  In  the  preemptive  policy,  when  the  schedulability  criterion  is  examined,  the 
time  constraint  accepted  earlier  is  checked  either  as  one  member  of  the  set  of  maximal 
convex  subintervals  or  as  the  constraint  that  sets  the  verification  window,  TCX. 

3s,  €  S(Iv)  :  TC’  n  s,  ^  <f>  V  TC'  =  TCn. 

Hence,  if  schedulability  is  verified,  then  TC'  is  not  affected.  In  the  non-preemptive 
case,  P'  is  verified  to  have  sufficient  laxity  as  a  member  of  1°,  and  therefore  accepting 
P"  is  possible  only  if  the  updated  laxity  of  P'  is  positive. 


K»*>. «*4_ «»  h»:t,<  l>»  I.l  t,>  |J^*litLfail>» i  l*i*l'i*>*  'll  *i*  *ll  I r Li' *  * 


4.1  Convergence  of  the  Alogorithms 

The  algorithms  presented  in  sections  3.3.1  and  3.3.2  contain  “unbounded”  loops  of  the 
form 

repeat  •  •  •  until  I4  ^  <f>. 

In  this  section  we  show  that  the  loop  is  bounded  to  at  most  two  iterations.  There  are  two 
cases  we  need  to  consider.  The  first  is  the  case  where  the  incoming  time  constraint  rC,n 
is  not  contained  within  any  other  already  accepted  time  constraint  in  the  calendar.  The 
second  case  is  that  where  there  exists  such  an  already  accepted  time  constraint. 

1.  :  TC ^  >  TCi„  :  In  that  case  v  is  initially  set  to  !FC,n  and  /<  is  initially  set  to 
Since  JQ TC^  :  TC ^  >  TCin,  I4  is  not  updated  in  the  classification  switch,  and 

hence  only  one  iteration  is  executed. 

2.  3TC P  :  TC\>]  >  TCin  :  In  that  case  v  is  initially  set  to  TCi„  and  I4  is  initially  set  to 

4>.  Since  3TC^  :  TC ^  >  TC,„,  at  the  end  of  the  first  iteration 

I4  =  {TC'k},  k  =  l,... 

such  that 

V*  :  TC'h  >  TCin. 

We  therefore  set  v  to  TC'max  such  that 

£TC'h  €  I4  :  TCk  >  TC L, 

and  start  the  second  iteration  with  reseting  I4  to  <f>.  If  the  second  iteration  ends  with 
I4^  <f>  we  have  a  contradiction.  To  show  it,  say  I4  #  <f>.  Therefore, 


But  then  TC'  also  satisfies 


which  implies 


3TC' :  TC'  >  TC' 


TC  >  TCin 


TC'  e{TC'k} ,  *  =  1,... 
that  contradicts  the  definition  of  TC'm. 


4.2  Convex  Interval  Schedulability  Guarantee 

4.2.1  Correctness  of  Goer sntee  in  Non- Preemptive  Scheduling 

In  order  to  show  that  the  guarantee  provided  by  the  non-preemptive  schedulabiliy  condition 
(Condition  1)  for  a  convex  time  constraint,  we  show  that  two  properties  hold.  First, 
consistency  between  possible  schedule  of  the  computation  interval  and  the  allowed  window 
of  occurrence  is  maintained.  Second,  an  accepted  constraint  is  not  in  conflict  with  the 
already  accepted  constraints,  and  a  possible  schedule  of  them  all  exists. 

If  Condition  1  holds,  then  by  the  definition  of  laxity  >0  we  can  write 

VP<  €  P°  :  Pi  T  TCi  VPj<  TCi  V  Pi  i  TCi  VPf  =  TCi, 

and 

Pin  T  TCin  V  Pin  TCin  V  Pin  i  TC{n  V  Pin  =  TCin . 

Hence,  executing  the  subintervals  {Pj}  and  Pin  at  a  schedule  which  is  exactly  as  the 
calendar  through  which  the  algorithm  verified  Condition  1  is  not  in  conflict  with  any  of 
the  time  constraint.  Each  execution  interval  is  within  the  occurrence  window  allowed  for 
it. 

The  assumption  that  all  the  already  accepted  time  constraints  have  been  accepted  by 
this  algorithm,  implies  that 

Vi,  j  :  Pi,  Pj  €  P°  A  i  it  j  :  P<  h  Pj. 

As  shown  in  [2]  and  by  the  definitions  in  Appendix  A,  from  a  disjoint  relation  P,n  n  PP, 
that  is  the  positive  result  of  the  test  in  Condition  1,  one  can  infer  the  existence  of  an 
idle  interval  T,  between  the  incoming  computation  P,n  and  each  of  the  already  accepted 
computations  Pj„  €  P°.  In  other  words 

3T,  :  PiMPin  V  Pin\\T,\\Pio, 

with  ||T«||  >  0  .  The  existence  of  such  a  Ts  for  computation  P,#,  whose  corresponding 
window  of  occurrence  TCi,  satisfies  TCi,  €  implies  the  existence  of  another  interval 
Ty,  for  computation  P,. 

3TV  :  Pi\\T'\\Pin  V  PinWW. 

P’s  corresponding  window  of  occurrence,  TCi,  satisfies  TCi  6  I\.  The  existence  of  Tv  is 
implied,  due  to  the  way  I{  is  constructed  from  I\  by  shifting  P<  to  the  right  to  produce 
Pi,,  such  that 

T%  1  Tv  V  Tx  =  Ty. 
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Similarly,  the  following  holds  for  the  right  side  of  the  verification  interval.  If  Condition 
1  holds,  then  each  computation  interval  has  at  least  one  possibility  to  be  scheduled  without 
a  conflict  with  its  constraint.  Furthermore,  as  in  the  left  side  of  the  verification  algorithm, 
Condition  1  implies 

3T.  :  Pu\\T,\\Pin  V  P<n||r,||P,., 

for  computation  interval  P,#,  whose  corresponding  window  of  occurrence  TC,o  satisfies 
rC<#  €  J|.  Hence,  by  the  way  /f  is  constructed  from  h,  we  can  have  a  Tv 

Ta  T  T,  V  Ta  =  T, 

such  that 

3T,  :  Pi\\T,\\Pin  V  Pin\\T9\\Pi, 

for  computation  interval  P<,  whose  corresponding  window  of  occurrence  TCi  satisfies  TCi  6 

h- 

4.2.2  CorrectneM  of  Guarantee  in  Preemptive  Scheduling 

Condition  2  constitutes  a  method  to  check  the  feasibility  of  a  preemptive  schedule  for  an 
incoming  convex  time  constraint  TC,„.  We  show  here  that  if  Condition  2  holds,  then  a 
feasible  schedule  exists. 

The  verification  of  schedulability  has  to  be  examined  for  two  possible  cases.  The  first 
is  the  case  in  which  the  verification  window  equals  the  interval  of  occurrence  of  the  new 
incoming  time  constraint.  The  second  is  the  case  in  which  it  is  not  equal. 

1.  TCa  =  TCin  :  From  the  first  test  in  Condition  2  we  know  that  Vs„  G  S(7v)  for  those 
t's  for  which  e„  =  Lit  TC° 

M  >  E  |J?II- 

Let  Pi  be  the  convex  computation  interval  of  time  constraint  TCi,  that  have  been 
“modified"  in  the  algorithm  to  the  relevant  intervals  in  1°  to  P?  and  TC°  respectively. 
Then,  by  summing  the  above  we  get 

£  IM>  E  ElWII>  E  E  llflnrCi.11. 

V«.eS(7v)  V«,€S(Jv)V»(«.)  V..eS(7v)Vf(».) 

The  right  side  of  the  above  equation  originates  in  the  construction  of  J,°  and  Js°. 
Equality  holds  for  It,  as  well  as  for  members  of  2{  and  Js°  whose  computation  intervals 
were  already  within  the  verification  window.  For  those  whose  computation  intervals 
were  “pushed”  into  the  verification  interval,  for  worst  case  simulation,  inequality  holds. 


Hence,  if  the  second  test  of  Condition  2  holds  for  TCin 

lire, -,,11  =  ifii  >  £  ||«.||  +  ||p,„||  >  E  £  11*711  +  HA.II 

V».€S(7v)  V«.€S(7y)V.(«.) 

and  we  can  conclude  by  replacing  Ey«,gs(/V)  with  Ev<:TC<€J»  to  get 

l|rcto||  >  £  jAnrci.ll  +  IIA4- 

V«:TC,e/* 

The  above  equation  simply  states  that  the  verification  interval  is  large  enough  to 
include  all  the  required  computations. 

2.  TC,  ^  TCin  '  In  this  case  TC,n  is  a  member  of  Jy,  and  definitely  a  with  a  “contained” 
relation  with  respect  to  the  verification  window.  Therefore,  if  the  first  test  of  Condi¬ 
tion  2  holds,  then  Vs,  6  S(Jy)  for  those  t's  for  which  a.  =  U,(,.)  TC° 

IM  >  £  11*711- 
*(•.) 

In  this  case 

TC°i  e  1°  V  TC?  =  TCin. 

As  in  the  first  case,  summing  all  the  cases  we  get 

£  IM  >  £  £  11*711 

v..€S(j„)  v..es(/v)vi(.,} 

where  one  of  these  is  P<„,  and  the  rest  are  members  of  1°.  So,  we  can  write 

£  IWI  >  £  £  11*711  +  IIA.II- 

v«.es(/v)  v«,gs(7v)  v*(*»)  i 

As  in  the  first  case,  the  construction  of  1°  yields 

E  IWI  >  E  E  ||J7ii+||iU  >  E  E  llflnrc.||+||j^||. 

V».eS(Jv)  V*.€S(7v)V«(«.)  V».€S(7v)V»:rC.e/«-{TC,>  ] 

Now,  when  the  second  test  in  Condition  2  holds,  then  ] 

lirc.ii  =  mi  >  E  IWI  +  llftll-  i 

v*,es(/v)  1 

Using  our  results  from  above  | 

\\TCS\\  =  mi  >  Z  E  II Pi  n  rc.il  +  IIP.II  +  IIPft.ll.  ] 

V«.eS(7v)V<:TCj€7<’-{TC,}  ] 

3 
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4.3  Non- Convex  Interval  Schedulability  Guarantee 

The  conditions  for  the  feasibility  of  a  schedule  for  non-convex  computation  intervals,  either 
for  a  preemptive  policy  (Condition  4)  or  for  a  non-preemptive  policy  (Condition  3),  are  in 
a  way  generalizations  of  the  conditions  for  the  convex  computation  intervals. 

4.S.1  Correctness  of  Guarantee  in  Non-Preemptive  Scheduling 

As  in  the  convex  case,  the  requirement  for  non-negative  laxity  in  Condition  3  assures 
that  no  conflict  exists  between  computation  intervals  and  their  corresponding  occurrence 
windows.  These  assurance  holds  both  for  the  incoming  new  time  constraint  and  for  already 
accepted  constraints. 

V/M  €  po  :  j+j  |  TCi  V  (+j  <  TCi  V  |+Jp/y)  1  TCi  v  (J  PtU)  =  TC„ 


1+1^  T  TCin  v  l+J  pW  <  TC,n  V  1+1  J.  TCin  V  y  =  TCin. 
i  i  i  i 

Hence,  each  computation  interval  is  within  the  occurrence  window  it  is  allowed  to  be. 

The  assumption  that  all  the  already  accepted  time  constraints  have  been  accepted  by 
this  algorithm,  and  the  property  of  preservation  of  the  algorithm,  imply  that 

Vt,  j  :  Pi,Pj  e  P°  A  *  ^  j  :  P& Pf . 

As  in  the  convex  case,  one  can  therefore  infer  the  existence  of  an  idle,  interval  Tz  between 
the  incoming  computation  Pin  and  each  of  the  already  accepted  computations  Pio  6  P°. 
In  other  words 

v*.  r> :  ?,<*>  £  Pi.  A  p/"’  €  P(n  : 

with  VAt,n  :  ||  >  0  . 

For  every  Pia  that  corresponds  to  TC,0  €  h  the  existence  of 

mto(lldM)ll)  >  0 

l|fl 

assures  a  feasible  schedule.  For  every  TC,-„  6  If,  since  every  computation  inteval  of  If  is  a 
shifted  right  version  of  a  computation  interval  of  Jj,  one  can  infer  the  existence  of  {Tj|*'n)}, 
such  that 

VJfc.n  :  T±k'n)  |  V  T^n)  =  T^'n). 


wv 


Thus,  we  can  use  this  property  to  conclude  ||TJJfc,n)||  >  ||TJ|fc,n)||j  that  yields 

«,n 

which  assures  a  feasible  schedule.  Similarly,  for  every  TC,-#  €  I, 

VJfc.n  :  rjM)  T  TV(M  V  Tik'n)  =  T$k'n). 

Since  ||7’tf(*,n)||  >  ||rji,n'||,  we  conclude 

min(||rl*'”)||)  >  0 

a,n 

which  assures  a  feasible  schedule. 

4.3.2  Correctness  of  Guarantee  in  Preemptive  Scheduling 

Condition  4  can  be  analyzed  in  the  same  way  that  Condition  2  has  been  analyzed  above. 
Here  we  examine  the  same  two  cases  as  above. 

1.  TCX  =  TCin  :  From  the  first  test  in  Condition  4  we  know  that  Vs„  6  S(Iv)  for  those 
*' s  for  which  sv  =  LJ,  TC° 

IKII  >  E  E  Ill’ll- 

Summing  the  above  and  considering  the  “unmodified”  computation  intervals  {P,}  we 
receive 

E  IWU  E  E  E  llfl‘lls  E  E  E  ll^|n)nrc(n||. 

v«.es(jv)  v«.es(/v)  v*(«.)  y  kipf^ep?  v«,es(JV)  v»:TC,€/°  vnipf^ePi 

If  the  second  test  in  Condition  4  holds,  then 

lircH.li  =  ||v||  >  z  IM  +  llfl.il  >  E  E  E  llfl“)ll  +  llfl.ll 

v«.e5(/v)  V«,GS(/v)  V*(*») 

and  we  can  conclude  by  replacing  Ey «,eS(Jv)  E,(*.)  with  Ev.:rc,e/»  to  get 

l|rCi„||  >  Z  Z  llfl"nrcjn||  +  ||fl»||- 

VS:TC(6J*  y nJ>fn)ePi 
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2.  TCa  TCin  :  As  in  the  above  case,  the  first  test  in  Condition  4  yields 

INI  >  £  lltfll. 

«(•.) 

Here 

TCI  €  1°  V  TCI  =  TCin. 

Summing 

£  II*. II  t  £  £  E  ll<,ll 

v*,es(iv)  v»,6S(/v)vi(*.)ykj>(»)  6p« 

where  one  of  these  Pfflr)  is  Pin,  and  the  rest  are  members  of  1°.  Hence, 

E  IM>  E  E  E  ll<.!)ll  +  lia.ll- 

V*»€S(/v)  V*«€S(Zv)  V«(#,):TC<€/* 

As  in  the  convex  case,  it  can  be  extended  to 

E  IM>  E  E  E  ||^"1nrc,n  +  ||pi„||. 

Vj.eS(Jv)  V,.6S(7v)  V«:TC,er»-{TC.>  *,j>00  6P((#>) 

From  the  second  test  in  Condition  4 

IITC.H  =  ||V||  >  £  M  +  Z  l|Ti‘>l|. 

v*,es(iv)  vk-j>lh)ep. 

Using  our  results  from  above 

IITC.II  =  \\v\\  >  E  E  E  ll/f 1  n  rc.|| 

»..6S(M«:rc,€7--{rc.)»„;Pi(.]eP.(_o 

+  E  IITi*1!!  +  E  Ill’ll- 

vkj»i4)eP, 

5  Concluding  Remarks 

In  real-time  systems,  the  scheduling  and  the  resource  management  must  be  integrated  in 
order  to  provide  the  support  for  guaranteeing  that  deadlines  are  to  be  met.  Furthermore, 
the  explicit  expression  of  time  must  be  the  base  of  the  decision  taking  processes,  to  pre¬ 
vent  undesired  dependencies  and  conflicts.  The  model  we  have  presented  here  and  in  our 
previous  works  ([15,16])  strongly  supports  the  above  motivation. 


In  this  paper  we  have  shown  a  set  of  temporal  relations  that  support  both  convex  and 
non-convex  time  intervals.  These  relations  support  reasoning  about  a  variety  of  temporal 
orderings,  for  continuous  intervals  as  well  as  for  intervals  that  contain  gaps.  Using  these 
relations,  we  have  formalized  temporal  properties  that  concern  schedule  feasibility.  We 
have  also  introduces  data  structures  called  calendars,  and  algorithms  that  check  and  verify 
conditions  for  the  feasibility  of  a  guaranteed  schedule.  The  correctness  of  the  guarantee 
is  discussed  and  analyzed.  Although  not  included  in  this  paper,  it  should  be  stated  that 
an  implementation  of  the  above  mechanisms  (data  structures  and  algorithms)  have  been 
carried  out  in  a  real-time  operating  system  project  in  our  university. 

Having  these  mechanisms,  each  of  the  system’s  entities  (in  our  case  objects  or  resources) 
is  explicitly  related  to  present  and  future  time.  This  fact  enriches  the  reasoning  for  planning 
purposes,  and  enhances  the  reliability  of  satisfaction  of  the  stringent  timing  constraints  of 
accepted  jobs. 


A  Interval  Relations 

A.l  Convex  Interval  Relations 

In  the  following  definitions  let  A  and  B  be  convex  time  intervals,  sucb  that 

A  =<  ,  t$  >,  B  =<  tf ,  tf  >  . 

A  set  of  thirteen  binary  relations  between  convex  intervals  is  proposed  in  [1]: 

•  equal  (A  =  B) 

tf  =  tfAt£  =  tf, 

•  preeeed  (A  -<  B)  and  its  inverse  succeed  (A  >-  B) 

*0<*Z, 


•  meet  (A  ||  B )  and  its  inverse  met-by  (B  ||"  A) 


=  * f. 


•  overlap  (A  0  B)  and  its  inverse  overlapped-by  ( B  0“  A) 

*2  <t£  <t£  <tf, 

•  itart  (A  T  B)  and  its  inverse  started-by  ( B  T“  A) 

*a  =  *2  <  *fi  <  **, 

•  during  (A  C  B)  and  its  inverse  contain  (B  A) 

t%  <tl<t$  <tf, 

•  end  (A  l  B)  and  its  inverse  ended-by  ( B  A) 

tf  <  ti  <  t*  =  tf . 

A  summary  of  these  relations  is  given  in  Figure  3.  The  relation  disjoint  (t»)  can  therefore  be  expressed 


A  x  B  =  (A  ■<  B)  V  (A  >■  B), 


and  all  the  containment  possibilities  as 


(A  t  B)  v  (A  c  B)  v  (A  i  B). 
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A.2  Non-Convex  Interval  Relations 

In  [10],  ways  in  which  non-convex  interval  relatione  are  derived  have  been  examined.  First,  a  non-convex 
interval  relation  can  be  generated  from  a  convex  interval  relation,  by  generalising  the  convex  relations  by 
means  of  functors.  Additional  new  relations,  which  are  not  dne  to  the  above  functors,  as  well  as  relations 
which  are  based  solely  on  the  first  and  last  convex  subintervals  of  the  non-convex  intervals,  are  enumerated. 

Let  C  and  D  be  non-convex  intervals,  and  let  {c,}  and  {4}  be  their  corresponding  sets  of  maximal  convex 
subintervals.  Let  #  and  Q  be  convex  relations  defined  in  section  2.3.2.  The  relation  functors  suggested  in 
[10]  are  listed  below. 


•  mostly.  C  mostly- Z  D  if 


Vij  £  D  :  3ci  £  C  :  c\Zdj. 


There  might  be  other  subintervals  in  C  but  not  in  D. 

•  always:  C  always- £  D  if  and  only  if  C  mostly-#  D  and  D  mostly-#*  C,  where  #"  is  the  converse 
relation  to  #. 

For  example,  C  always- >■  D  (Le.  C  always-contains  D)  if  and  only  if 
C  mostly- >•  D 

Vdy  €  D  :  3e<  £  C  :  c,  >  d}  , 

and  D  mostly-C  C 

Va  £  C  :  3dj  £  D  :  dj  C  c{. 

•  partially.  C  partially-#  D  if  and  only  if 

X  —  {xj}  =  {c<,  di :  CiZdi}  ^  <fr, 

{C-X}r\{D-X)  =  t. 

Notice  that  all  the  elements  <n  £  C  and  di  £  D  for  which  c,#d ,•  does  not  hold,  must  be  disjoint  for  C 
partially-#  D  to  hold. 

•  sometimes:  C  sometimes-#  D  if  and  only  if 

X={zi}  =  {ci,di:  aZdi}?*. 

•  disjunction:  C  #  V  ...  V  Q  D  if  and  only  if 

Vc,-  £  C,  Vd,  e  D  :  Ci  Zdi  V  ...  V  <*  Qd}-  V  a  M  dj. 


Another  functor  we  find  important,  one  which  is  not  defined  in  [9,10]  is 
•  totally.  C  totally-#  D  if  and  only  if 


For  example,  C  totally— <  D  if  and  only  if 

Viy  €  D  :  Vcj  6  C  :  c<  dy, 

which  means  that  the  rightmost  maximal  convex  interval  of  C  precede*  the  leftmost  maximal  convex  interval 
of  D. 

Another  example  is  the  non-convex  intervals  disjoint  (ST)  relation,  that  can  be  expressed  as  "totally- m*, 
meaning 

V«fy  €  D  :  Vc<  6  C  i  Cj  K  dy. 

In  addition  to  non-convex  relations  generated  from  generalisation  of  convex  relations  by  means  of  the 
above  functors,  there  are  important  relations  that  cannot  be  generated  this  way.  One  category  of  such 
relations  consists  of  new  relations,  out  of  which  we  emphasise  here  the  bar  relation  ([10]).  This  relation  is 
needed  for  expressing  predicates  on  convexity  of  intervals. 

•  bar.  a  relation  between  two  non-convex  intervals,  denoted  C  *-*  D,  whose  union  is  convex. 

C  *-*  D  if  and  only  il  C  U  D  =  C  &  D. 

The  relation  is  symmetric  and  commutative. 

Another  important  set  of  relations  is  based  on  convex  relations  between  the  leftmost  and  rightmost 
maximal  convex  subintervals  of  non-convex  intervals.  Generalisation  by  means  of  functors  cannot  generate 
all  these  possible  relations,  because  these  relations  are  based  on  specialisation  of  particular  subintervals,  the 
leftmost  and  the  rightmost  ones.  Let  <C  denote  the  leftmost  maximal  convex  subinterval  of  non-convex 
interval  C,  and  let  t>C  denote  the  rightmost  maximal  convex  subinterval  of  non-convex  interval  C.  Some 
relations  based  on  these  subintervals  can  be  expressed  by  use  of  the  functors.  For  example, 

C  totally— <  D  if  and  only  if  >C  -<  <D. 

However,  a  large  variety  of  relations  cannot.  For  example, 

•  meet  non-convex  interval  C  meets  non-convex  interval  D,  denoted  Cj|D,  if  and  only  if  >C  j|  <D. 

Another  example  is  the  containment  property.  We  have  generalised  above  one  possible  containment  with  C 
always- >•  D  (i.e.  C  always-contains  D ),  where  each  of  the  maximal  convex  subintervals  of  D  is  contained 
by  a  maximal  convex  subinterval  of  C.  However,  there  are  other  containment  properties.  For  example, 

•  turroundi  non-convex  interval  C  surrounds  non-convex  interval  D,  denoted  CS>D,  if  and  only  if 

(+){<?}  »(+J{Z>>. 

For  allowing  reasoning  on  subintervals,  we  therefore  write 

((<C-<  <D)V(<C0<U)V(<C  ||  V  (<(7<  <D)  V  ( <C  1  <D)) 

A 

(( >C  >~  t>D)  V  ( >C  0“  >D)  v  ( >C  ||M  >D)  v  ( >C  >  >D)  v  ( >C  T  >P)). 

The  expression  is  much  simpler  for  the  disjoint  case 

(<7ST2?)  A(<C  x  <D)  A(>C  >-  >D). 


ass 
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A  subset  of  relations  that  are  based  on  the  leftmost  and  rightmost  maximal  convex  subintervals,  concerns 
the  relative  start  and  end  of  the  non-convex  intervals.  In  [10]  the  following  relations  are  enumerated: 

•  start-before :  C  ]<  D  if 

((<<?-<  <Z>)  V  (<C  <2><D)  V  (<C  ||  <D)  V(<Cc  <D)  V  (<C  i  <D)). 

•  atari-after.  C  f>  D  if 

((<<7  v  <JD)  V  (<C  0“  <Z>)  V  (<C  ||*  <Z7)  V  (<C  <  <D)  v  {<C  l  <D)). 

•  start- at  C  f  D  if 

<C  f  <D. 

•  end- at  C  \  D  if 

>C  i  >D. 

•  end-after.  C  l>  D  if 

((l>Cv  >D)  V  ( >C  0“  >D)  V  (  >C  ||*  >D)v(>Cc  >D)V(>C  i  >£>)). 

•  end-before:  C  1<  D  if 

((>C-<  >£))  v  ( t>C  0  >D)  V  ( >C  ||  >D)  v  ( >C7  c  >D)  v  ( >C  J,  >£>)). 

Finally,  a  very  important  calssification  of  the  above  relations  can  be  derived  according  to  properties  of  non* 
intersecting  versus  strictly  intersecting.  The  disjoint  properties  are  of  extreme  importance  for  the  allocation 
which  is  to  verify  schedulability  of  objects.  We  have  already  described  above  the  disjointly-surround  relation. 
Another  important  disjoint  relation  is  the  following. 

•  disjointiy- overlap:  Cm  0  D  if  and  only  if 

(<7STP)  A  ( <C  -<  <D)  A  ( j>C  -<  >D)  A  (<iD  -<  >C). 

If  C  is  the  set  of  already  guaranteed  services  at  a  resource,  and  D  is  a  new  request  for  a  service  at  this 
resource,  then 

((Cfi'D)  A  (C7>£>))  V  (Cn0  D) 
can  be  a  proper  schedulability  condition. 
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